Dynamic Software Update (DSU) procedures have been developed to allow code and data updates such as critical security patches and upgrades to be applied to a software program without downtime. Challenges can arise in managing global variables when performing a dynamic software update. Global variables are variables that are accessible to all the functions referenced in a program, are typically declared on top of all functions, and once declared they remain in memory throughout the runtime of the program.
When a program is first loaded, it is allocated a unique process address space in virtual memory that is mapped to a corresponding space in physical memory. The memory is used for executing instructions and storing data. In environments that support DSU, multiple versions of instructing code and data can be allocated different version address spaces within the process address space. Typically, a particular program version will have version address space allocated to it that will include space for instructing code and space for data. The address space for data can include a data segment assigned for global variables. Accordingly, in a DSU environment where multiple versions of a program may exist concurrently, multiple data segments that include the same global variables can occur, which can give rise to global variable management and migration issues.
This issue has been addressed in various ways in the past. For example, some DSU systems manage global variable migration by performing a memcpy to the address of a global variable in the data segment of a new program version from the address of the global variable in the data segment of the old program version. This requires that the new program version receive the addresses of the global variables in the data segment of the old program version and then access the global variable values via pointer dereferencing to get the values. Such a system requires that all program threads be quiesced during global variable migration to avoid race conditions for the variables. (See for example: Kitsune: Efficient, General-purpose Dynamic Software Updating for C; Christopher M. Hayden, Edward K. Smith, Michail Denchev, Michael Hicks, Jeffrey S. Foster; University of Maryland, College Park, USA; https://www.cs.umd.edu/˜tedks/papers/2012-oopsla-kitsune.pdf)
Other DSU systems attempt to prevent race conditions and/or mitigate thread migration risks by having the new version of the program manipulate the global variables in the old program version's data segment directly via pointers. A downside of this approach is that the new program version needs to reference the global variables via pointer redirection, which negatively impacts performance overhead. Further, this approach can mandate some recompilation of the new program's shared library components with a tool that manually transforms direct accesses to indirect accesses. In a plugin architecture where the premise is that third party plugin developers are only required to supply binary code, asking for source code for recompilation is not feasible. Additionally, because a newer program version's code refers to the old version's data segment, one cannot simply dlclose the older version, even after all threads have migrated off the older version onto the new version.
Accordingly, there is a need for a DSU system that can facilitate global variable migration with out requiring system quiescing, does not require access to program source codes, and allows unused program versions to be de-allocated from the process address space.